-
Notifications
You must be signed in to change notification settings - Fork 0
[PM-5756] Comment on originating PR with BIT results #373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Great job! No new security vulnerabilities introduced in this pull request |
a8b5928
to
27d633b
Compare
# Only post back to the PR if there was a failure since test-all has the | ||
# typical config case covered for success feedback |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reasoning here being, we don't need to be overly noisy if everything looks good, but we still want to alert if these cases fail.
.github/workflows/test-all.yml
Outdated
|
||
- name: Communicate BIT failure on originating issue | ||
uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea # v7.0.1 | ||
if: failure() && github.event.client_payload.origin_issue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I intentionally did not use step failure (of, for example, the playwright-tests
step), so that we still report back if BIT failed somewhere else. If we find this creates too much noise (like if the test login process starts to fail from a ui update), we can target the step failure (by id) instead.
If the action is cancelled, neither case fires.
27c6be4
to
ee24ed7
Compare
…to use GITHUB_TOKEN
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens with the azure steps if we run this manually? Do the Azure login steps also fire? Do we want to scope those to only run when this is triggered from a dispatch?
Good call; yeah they would (they fire again when building the dotenv in in "Create dotenv file" step as well). I'll give it another look... 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you @jprusik !
🎟️ Tracking
PM-5756
📔 Objective
This adds repository dispatch triggers (on "trigger-bit-tests" event) to the Test-all and Test-all-custom-flags workflows. The workflows will now additionally comment with the BIT results on the originating PR.
(The
ENABLE_PR_FEEDBACK
var can be updated to a value other than"true"
(or even deleted) to turn off commenting on the origin PR. )The corresponding
clients
work: bitwarden/clients#15960Testing
Permissioning and commenting tested/verified in #375; receipt verified in bitwarden/clients#15988
📸 Screenshots
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes